29-Dec-79 18:15:04-PST,533;000000000001
Date: 29 Dec 1979 1815-PST
From: Lenat
Subject: Nasty Bug
To:   GREINER

Russ,

The trace file TRACE.DEC29;1  is noteworthy for the very nasty
bug of Non-numeric ARG in UP-RELEASEBLOCK, when fed an apparently
decent argument.  As it shows, I then walked through the interpreted
version of the fn, and it worked fine.  I suspect that the funny
CLISP is getting compiled wrong, or something similar.  Sigh.
Rather than risk clobbering the KB, I am deleting the .page files
and trying all over again.  

Doug

-------
 1-Jan-80 14:59:59-PST,703;000000000001
Date:  1 Jan 1980 1459-PST
From: Lenat
Subject: Amazing LISP clobbering
To:   GREINER

As the JAN01 trace shows, LISP was totally demolished somehow (maybe
by me, maybe by someone else); CAR of NIL was clobbered with LAMBDA,
and funny non-evaluations began to happen.  I was thrown in a state
where my characters did not echo, and eventually found out that they
WERE being received, though there were still many inexplicable breaks
and bugs and NON-NUMRIC arg erros where they whouldn't have been.
Look it over and see if you have any ideas.  I made HEURS, but
gave up trying on RLL and its fns. Sigh.  I will now see if HEURS
is ok, and if not delete the latest version.

Doug
-------
14-Dec-79 17:18:30-PST,000001051;000000000001
Date: 14 Dec 1979 1718-PST
From: CSD.LENAT
Subject: score --> sumex
To: csd.greiner

this is not trivial..  I just tried!

One bug (perhpas omnipresent) is the presence of <csd.smith> and
<csd.lenat> etc. at various places.  I suggest omitting all such
anglebracketed things, and making the user responsible for assigning
a proper athway so that somehow he will get CORLL, UTIL, etc. by
just using their filenames, not needing ANY usernames as prefaces.

Also:  I needed the perstatus.com file and forgot to ftp it.

Also:  the OverallStartUp function called WHENCLOSE, a function
that did not exist at SUMEX.  Where shold it have been defined?
I ↑D'ed out of the earlier file at the point it (CORLL.COM) requested
PERSTATUS.COM, so the bug might simply go away when PERM... exists.

Good luck.  Please do this before Monday, and send me a note when
it's all usable.  Feel free to copy the file directly from my
area at SUMEX (they come from <CSD.LENAT>, not <HPP.MOLGEN :   I was
willing to risk it!!)   



Doug
-------
16-Dec-79 17:23:04-PST,000001426;000000000001
Date: 16 Dec 1979 1723-PST
From: CSD.JJF
Subject: Once again
To: CSD.SMITH
cc: CSD.GREINER, LENAT at SUMEX-AIM

Another painful bugbite! Dave: See the dribble file TROUBLE..1, if you have
a chance. As I saw the list space dwindle, as, it appeared, nothing was being
bumped out, I ↑H'ed and (UP-BUMPUNITS)ed. Mistake? Numerous units got bumped,
and I got back enough space to do some more things. However, when I tried to
write the KB, I found one unit had been screw up. What follows is an attempt
on my part to recover that unit's value, from an earlier version of RLL renamed
TEMP for this sherade (sp). You will note RLL grew increasingly unhealthy from
then on... I finally abandoned it.
	Comments?  Could that UP-BUMPUNITS have caused this grief? Or was 
whatever was preventing the regular bumping have been the true culprit for this
problem as well?
	On another front, I notice the "Loading ..." and "Bumping ..." messages
litter the summary files. Seems to me the straightforward soln to that is to
use my WRITELNTTY functions, rather than the WRITE, one, for those Load and Bump
messages.

Doug: I'm now going to transfer the following files from <CSD.LENAT>@SCORE
to <MOLGEN>@SUMEX:
RLL, RLL.COM, RLL.KB, HOBBIT, HOBBIT.COM, HOBBIT.KB, UTIL, UTIL.COM
& RLL.SUMMARY (all of which are the most current.)

If I encounter any problems, there will be a follow up message.
Ciou,	Russ
-------
18-Jan-80 15:47:45-PST,00000001204;000000000001
Date: 18 Jan 1980 1547-PST
From: CSD.LENAT
Subject: Total Garbage
To: CSD.GREINER
cc: CSD.SMITH, GREINER at SUMEX-AIM

The property lists of most of the HEURS units were totally garbled!
I assume this stems from the bug Dave mentioned (i.e., UF-CANCELNETWORK)
does NOT reset the values of units (the atoms) to NIL, hence the system
thinks it has the current stuff in core (e.g., the address on the file)
when in fact it doesn't.  Beware of using JUNK.  In general, don't make
sysouts like that.  Make one just prior to doing OverallStartUp, and that
should be all.  Please fix (undo?) the GetValue macro, and recompile
UTIL, and remake a sysout, called RLL or EUR.  We must get together and
work out a system whereby one (1) running version exists at all times.
This is the Nth time I have tried to work on my heuristics KB and lost
because of CORLL and RLL not doing Get and Put properly.  This is just the
sort of thing that kept Bob Blum from using UNITS, magnified 10 times.
This will be combined in a big reorganization of file space, creation
of Eurisko directories, etc.  Let me know your ideas on the way that
you think such should get parcelled out.  Thanks.
Doug
-------
 9-Feb-80 20:43:31-PST,000000785;000000000001
Date:  9 Feb 1980 2043-PST
From: CSD.GREINER
Subject: Trouble with CORLL, or Diagnose
To: csd.smith
cc: lenat at SUMEX-AIM, csd.greiner

Everything was working superbly until I attempted to write out RLL.
UU-DIAGNOSE found any number of problems with it. (No problems with
any of the other KBs.) Figuring (that is, praying) that it was just
some error with the diagnostic function, I spent some time trying to
step thru its execution. 

Dave: Does the value cell of a unit still hold the same value as it
used to? (Ie did I base Diagnose on some assumption which is no longer
true?) If not, could you examine that diagnose function?

Thanks.

(Doug: I've sorted out a few more things in my mind - will reveal all
tomorrow, or when next I see you.)

Russ
-------
22-Mar-80 12:37:46-PST,000000778;000000000001
Date: 22 Mar 1980 1237-PST
From: CSD.GREINER
Subject: Clobberage
To: csd.smith
cc: lenat at SUMEX-AIM, csd.greiner

I just noted that the OLD.KB file has, apparently, been clobbered (it somehow
lost the pointer to the unit list, and so reported that it had no units...)
Fortunately the backup copy (actually, the version 2 earlier) has everything
I need, so nothing was lost.
	I just wanted to report this, in case it is somehow indicative of a
more general problem.
(By the way, I examined all the trace files relevant, and could not find any
obvious cause for this problem -- each time it was closed, it seemed to either
run the StandardFinishUp function (when OLD correctly pointed to a unit index),
or not, when it didn't.)
	Any thoughts?
Russ
_
-------
25-Mar-80 18:21:59-PST,00000001676;000000000001
Date: 25 Mar 1980 1821-PST
From: CSD.GREINER
Subject: Ok, I think it works now
To: csd.smith
cc: lenat at SUMEX-AIM, csd.greiner

After a bit of hacking I think I ressurected (sp) RLL to a functional state.
(Fingers crossed, of course.) Looking closely at the clobberage, I feel certain
my monkeying with RLL.FREEBLOCKINDEX was NOT the problem -- the area affected
was nowhere close to where I was tampering, and I was being careful and avoiding
dead-lock conditions. However, it remains likely the damage was done when some
stack overflew (overflow-ed?), as things might not get the rest of the way done
under this condition...
	At any event, I've another trouble to report: After restoring the values
needed (using UU-RETRIEVE from the RLL.KB on <CSD.GREINER>,) I compacted this
KB. The subsequent Diagnose showed that something wasn't quite - one of the 
units which had caused me grief (AfterGetValue by name) was still conflicting
with a free block entry. Undaunted, I then attempted to UA-DELUNIT it out of 
existence, unsuccessfully. I finally simply removed it from RLL.UNITINDEX by
hand, shivering as I went... The diagnosis turned up clean, and we're now at
the present. Any thoughts? Perhaps its because the starting address of this
unit was too high, (and hence it was now a BIGNUM?) or because it was added
when the FreeBlockList contained but a single entry?
	Please examine the TRACE*.MAR25, for * := 1 to 4; and let me know what
you find.

(By the way, do not be alarmed by the gradual increase in OLD.KB and OLD..'s
size -- I'm storing old [hence the name] units and files there, for save
and innocuous, keeping.

Russ
-------
18-Apr-80 21:46:19-PST,00000001173;000000000001
Date: 18 Apr 1980 2146-PST
From: CSD.LENAT
Subject: RLL STATUS
To: CSD.GREINER, CSD.SMITH

As usual, I only work on RLL on those nights which I get no status
message.  Apparently, the BAD units (MySlotsNowOrdered, etc.) were not
in RLL, today's crop WERE put back in, the file has been preened and
compacted, and all is right with the world.  TEMP.EXE now contains
the sysout with all the KBs, etc., successfully (?) loaded in.  I
will be working on this for a while, and then remake temp.exe, and
PERHAPS remake the kbs; so check to see which .exe has the latest time.
Thanks for patching this up.  I presume that the advising of putunit
has NOT been done yet; let me know if (when) it is.

We should write up RLL for AAAI; I propose an article by
Greiner, Smith, and Lenat (in that order) based largely on material
Russ is composing, gone over and partially reworked by me, with
a short but sweet treatment of CORLL by Dave (also reworked by me).
Most of this can and should be done in the next 5 days or so.  Dave:
if you are writing up Wheeze for AAAI, you can't have your name on his
paper ("this paper") too, due to AAAI rules.

Doug
-------
22-Apr-80 17:05:10-PST,00000000439;000000000001
Date: 22 Apr 1980 1705-PST
From: CSD.LENAT
Subject: RLL OVERLAPPING
To: CSD.GREINER
cc: CSD.SMITH

It does.  See the end of today's tracefile if you want.
Basically, the 2 units AllIsas and MySlotsNowOrdered both start at
loc N, and so does a free block.  I presume the fix is to
simply elim. the free blocks from the free block list, but this isn ot too 
satisfying.  Also, there is a hole in the file.
Sigh.

Doug
-------
 1-May-80 04:30:04-PDT,000000823;000000000001
Date:  1 May 1980 0430-PDT
From: CSD.LENAT
Subject: STATUS
To: CSD.GREINER

All is ok. USEME means it. THe *.EPAGE files on your direc gowith it;
do not delete them or USEME until you're sure you've closed HOBBIT and
(I believe) remade that file; check FILES?)

I had to CLOSE) almost immed., since space was going FAST!! Just barely managed
to before all space was gone.  What happened?  Neither gainspace nor
bumpunits had any appreciable effect on increasing list cell space.
When I closed and reopened in fresh sys, all went well (so far, anyway);
let's keep an eye out for this recurring; maybe you had some big
variables being built up, perhaps unknown to you (e.g., via tracing or
breaking...)?

I will be in a mtg from 11-12 with Ed, free before and after for AAAI paper 
grind.

Doug
-------
 3-May-80 22:16:47-PDT,000000377;000000000001
Date:  3 May 1980 2216-PDT
From: CSD.LENAT
Subject: BUG
To: CSD.GREINER

Overlapping units galore.  Fixed most (I hope).
RLL is ok; hobbit may be bogus.

USEME is fresh, and corresponds to *.page but NOT to *.epage!!

MUCH trouble with running out of space when trying to CLOSE).
Can we take care of that somehow?  Gainspace just squeaked me thru.

Doug
-------
 7-May-80 23:39:06-PDT,00000001441;000000000001
Date:  7 May 1980 2339-PDT
From: CSD.GREINER
Subject: All yours
To: csd.lenat
cc: csd.greiner

Curious: When I closed the KBs, they all checked out ok. I then remade
a RLL sysout, and decided to attempt to remove virtual links in RLL
(I hadn't for that first close, out of cowardice.) After removing some
560+, I diagnosed RLL, which I found to be strewn with holes and overlapping
blocks! Then I remembered your REL file. I have re-SYSOUTed RLL.EXE, to
include that file; I also stored a copy of RLL.KB on my area, for safe keeping.
(When space got scarce I moved your HOBBIT.NEWKB to my area as well.)
Unfortunately I have to go now, but we should START), CLOSE) and answer Y
to the RemoveVirtualSlots question, and see if REL starts to complain.

Question: what if RLL.FREEBLOCKINDEX is not somehow passed by on the incorelist
- could this explain why someother unit "tries" to get put twice, that
during a MAPC along the destructively modified list some pointer gets mis-
directed? Or does Dave COPY that list first?

Onto what I've done:
I think I've figured out how to handle arbitrarily embedded Composition's
and Unioning's, (and their relatives like OrderedComposition, and OneOf) -
still need a bit more work on embedding Starring, and a few others.
New slots can be created on the fly, and get all their essential properties
deduced via HighLevelDefn, as desired.

See you tommorrow.
	Russ
-------
 9-May-80 14:50:44-PDT,00000000824;000000000001
Date:  9 May 1980 1450-PDT
From: CSD.GREINER
Subject: Fixed
To: csd.lenat
cc: csd.greiner, csd.smith

Turns out the RLL.KB file itself had troubles - even though Diagnose
had given it a CLean bill of health earlier. There were a number of units
which each overlapped with an entry on the free block list -- which one 
UU-COMPACT cleaned up. As before, the free block index was well formed
and everything - but it just didn't correspond to the current version
of RLL.PAGE... and all this was done with your REL file loaded in.

Note: in all cases, the problem appeared to be that the unit had been
assigned some portion of a free block, and tried to give the rest of it
back, but for some reason that modification never got made (ie the 
result of the RPLACA was never stored.) Any theories?
	Russ
-------
 9-May-80 15:28:40-PDT,00000393;000000000001
Date:  9 May 1980 1528-PDT
From: CSD.LENAT
Subject: Re: Fixed
To: CSD.GREINER
In-Reply-To: Your message of 9-May-80 1450-PDT

How inefficient is the following:
If the existing space is too small (or the unit is brand new), write
it out at the end of the file (i.e., ignore all but the final freeblock).

We can do this until the problem recurs and is tracked down.

Doug
-------
13-May-80 12:41:15-PDT,00000000828;000000000001
Date: 13 May 1980 1241-PDT
From: CSD.SMITH
Subject: bumping units
To: CSD.GREINER, CSD.LENAT

My suspicion about units not getting bumped out when necessary is that the
GCTRP exit only triggers when you cross the threshold, but not if you were
under it to begin with.  Thus when free list storage falls below 10000 UP-
BUMPUNITS gets called, but if not enough units are bumped to bring it back
over 10000, it wont get invoked on the next garbage collect.  To remedy this
I have reinvoked the extra loop in BUMPUNITS which does a RECLAIM at the end
of bumping.  If free list space is not over 10000 it bumps again.  This may on
occasion cause you to get into an infinite bumping, collecting loop.  If so jus
break and RETFROM  UP-BUMPUNITS.  I hope this fixes the problem of running out
of space.

Dave
-------
 7-Jul-80 16:59:11-PDT,00000257;000000000001
Date:  7 Jul 1980 1658-PDT
From: CSD.GREINER
Subject: Size of RLL
To: csd.lenat
cc: csd.greiner, csd.hines

RLL.PAGE and .KB seems to have doubled in size - from 189 pages, to 378.
Any ideas why? Note the other KBs have behaved themselves.
-------
14-Jul-80 16:06:51-PDT,00000000332;000000000001
Date: 14 Jul 1980 1606-PDT
From: CSD.SMITH
Subject: Re: News
To: CSD.GREINER
In-Reply-To: Your message of 9-Jul-80 1347-PDT

Huh?  UF-RENAMENETWORK just renames <>.UNITINDEX, <>.FREEBLOCKINDEX and 
<>.STATUS, thus the <new>.STATUS has all the slots of the <old>.STATUS.
What do you mean by "copies all the slots".
-------
21-Jul-80 11:52:09-PDT,0000604;000000000001
Date: 21 Jul 1980 1152-PDT
From: CSD.GREINER
Subject: ... and all is NOT well.
To: csd.lenat, csd.smith
cc: csd.greiner, CSD.HINES

	After writing out the kbs (last night,) I attempted to use them today.
Unfortunately, RLL.KB appears clobbered! The data at position 0 (where
the address of the unit index is stored) is, I think, ill formed --
being a four-tuple, ending with T. When I closed there was  a unit not
on incore list -- might this have screwed things up?
	I'll hack on it for a while, and let you know what happens. Until
then, RLL is unusable. Damn, damn, damn!
	Russ
-------
22-Jul-80 16:53:34-PDT,0000001639;000000000001
Date: 22 Jul 1980 1653-PDT
From: CSD.GREINER
Subject: Follow up on trouble:
To: csd.smith
cc: csd.greiner, csd.lenat

Dave,
	I left the naughty RLL kb on my directory, as BADRLL.KB.
A relevant dribble file is <CSD.RLL>TRACE.JUL20; which shows the files being
closed. The fact that it failed to find any extraneous virtual slots is
significant -- they were there.  Note a unit in the in-core-list was not incore.
UU-RETRIEVE was able to find (old versions of) various units on BADRLL, so the
first S-expression in that file does indeed point to a version of the unitindex.

Question: Should CORLL (redundantly) store with unit its name, and perhaps a time
stamp? That way if the unit index gets lost, as it did here, it would still be
(remotely) possible to reclaim some of the data -- by walking thru the file,
collecting well-formed S-expressions which correspond to the last puts of this
unit. In case of ties, the user could be queried which candidate was appropriate.
Note this would be non-trivial, as the naive READ function would scan the entire
file if ever some list had its closing parenthesis overwritten...
If the Fred unit was enterred as "(Fred 46 <Fred's data>)", we wouldn't encounter
the troublesome NIL problem, which had forced us to surround each entry with
CRs.

I have continued to modify various CORLL functions, storing these in
<CSD.RLL>HOLD.COM. After you've returned, when you''ve a moment, we should
discuss this alterations.  CORLL might also want a function like CleanWS,
which (essentially) allows the user to read, but not modify, the external files.

Thanks.
	Russ
-------
23-Jul-80 18:54:03-PDT,000001200;000000000001
Date: 23 Jul 1980 1854-PDT
From: CSD.GREINER
Subject: The trouble is caused by:
To: csd.smith, csd.lenat
cc: csd.greiner

?. I was able to localize it, though. <CSD.RLL>RLL.KB.1, written circa
6:42 PM 22-Jul, diagnoses ok. Its successor, <CSD.LENAT>RLL.KB.115,
written 23:36 PM 22-Jul, however, has a world of problems.
This metamorphesis (sp) took place on <CSD.GREINER>TRACED.JUL22.
I'll leave a copy of this on your desk, Dave; as well as a copy of it
on line.  You'll note UU-DIAGNOSE gave it a clean bill of health --
perhaps it caused its ailements as well?
	Side issue: RLL grew from 191 pages to 217 over that 2 hour session.
That came after a prior growth spurt; after a packing. I'll grant that's not
too unreasonable; but perhaps we could slow it down by giving each unit a
bit more breathing space...
	Final note to Dave: (At least during this debugging phase,) 
when printing out the name of the network being
openned, or closed, it would be useful to see the full name -- esp the name
of the directory. Optionally it would be nice to see what time stamp had been
inserted into the file, as well.  
	Needless to say, Doug, RLL is still unavailable.
Russ
-------
25-Jul-80 18:31:39-PDT,00000548;000000000001
Date: 25 Jul 1980 1831-PDT
From: CSD.GREINER
Subject: Its too elusive for me.
To: CSD.LENAT, CSD.SMITH
cc: csd.greiner

Still couldn't find that bug. I was trying to recreate the clobberage of the
22nd of July, based on the Dribble file. This time that fiend failed to
exert himself.
At any event, RLL seems in working shape;
it passed Diagnose without complications. I'm now where I was the night
of the 22nd. Onward!
	Russ

Doug: I'm still awaiting comments on the memo. It would be nice to get
that out of the way soon.
-------
27-Jul-80 21:14:03-PDT,3724;000000000001
Mail-from: ARPANET site SU-AI rcvd at 27-Jul-80 2113-PDT
Date: 27 Jul 1980 2114-PDT
From: Russell Greiner <RDG at SU-AI>
Subject: Crisis averted
To:   csd.lenat at SU-SCORE, csd.smith at SU-SCORE
CC:   csd.greiner at SU-SCORE  

Well, I now have proof something funny is going on with CORLL, recorded
in TRACE.JUL27. (After ignoring the first two hundred pages of this
session log,) you'll find that before performing a UP-PUTALL, the
unit RLL.STATUS knew it had been modified, but the list stored on RLL
didn't -- hence after UP-PUTALLing, RLL.UNITINDEX had not been written
out!!  When I added it, by hand, to RLL's incore list it was, indeed,
put onto the file, and all was saved.
	Temporary solution: add to UP-PUTALL a (UP-PUTUNIT ...UNITINDEX) before
the (SETFILEPTR ... 0) stuff, to insure it has been written. You'll
note, from the trace file, that no other unit caused any trouble, only this
one.
	Comments: (1) Does INTERLISP do the right thing with things
declared to be GLOBALVARS, which really are SPECVARS -- for example,
UP.BUMPFLG? Is it possible there really is a deadlock type problem,
which we'd not even considered, as we had figured that this was, indeed,
a secure region? (This might be worth testing explicitly. Hopefully the
fact that this is a precarious advice to function called only in an
interrupt will not make this any different.)
Detracting plausibility from this comment is the fact that UP.TRACEFILE
seems to have worked perfectly, and it is a funny GLOBAL but should be
SPEC.
	(2) I've observed an overwhelming number of list GCs occur during
the RPLACD done to update the incore list. Could the following happen:
While both EURISKO.UNITINDEX and EURISKO.FREEBLOCKINDEX are swapped out,
the user calls for a new unit, U.
As RLL is RPLACDing the variable, EURISKO, to indicate U is now incore,
a garbage collect occurs, which, in turn, calls UP-BUMPUNITS. 
IE we were performing (RPLACD EURISKO '(U)).
Now we have to read in EURISKO.FREEBLOCKINDEX,
which requires first reading in EURISKO.UNITINDEX.
So when the interrupt is over, the value of EURISKO is 
(EURISKO.PAGE EURISKO.UNITINDEX EURISKO.FREEBLOCKINDEX), as desired.

	We now continue with the RPLACD mentioned above, which
led to this whole escapade. It, of course, continues; and, in the
end, the value of EURISKO is, of course, (EURISKO.PAGE U).
It forgot about EURISKO.UNITINDEX and EURISKO.FREEBLOCKINDEX!!
	This would explain the situation, sorta. 
You'll note the FREEBLOCKINDEX need NOT be in same perdicament as the
UNITINDEX, as it is possible the FBI was not changed, whereas the UI was.
This whole scenario could NOT occur if interrupts were NOT allowed within
this RPLACD. Here's where comment (1) comes into the scene: maybe turning
it off in UP-GETUNIT didn't work... Or maybe something turned it back on?
(could it have been given an argument in this place?)
	Well, play with that.

I spent the day putzing around. Creating a new unit should be yet even
faster now - perhaps by an order of magnitude, due to opportune caching.
(Expect the first time to be a bit slower, of course.)
Everything should work; I took the precaution of DIAGNOSEing RLL,
which passed. 
Also, I should mention the latest versions are still on <CSD.RLL>. 

	Doug: Can you send me a pointer to where the RLL Position Paper,
for the conference in SD, is located. Or should I write it? Either way,
it should be done soon. 
[Title  suggestion: "RLL: The Ultimate KE Builder", as it should follow
a presentation on "RLL: The Ultimate Representation Language".
Both times, with apologies to GLS...]

	When should we get together to discuss the RLL memo? (Subtle, huh?)
Russ


 9-Aug-80 21:48:03-PDT,1036;000000000001
Mail-from: ARPANET site SU-AI rcvd at 9-Aug-80 2147-PDT
Date: 09 Aug 1980 2147-PDT
From: Russell Greiner <RDG at SU-AI>
Subject: Trouble with UU-COMPACT 
To:   csd.smith at SU-SCORE, csd.lenat at SU-SCORE
CC:   csd.greiner at SU-SCORE  

Dave -
	I tried using the new UU-COMPACT, and ran into a heap of trouble:
The first time I tried it, while CONNected to <CSD.RLL>, I had two or three
?QUOTA exceeded errors en route; and figured that was why the resultant
RLL grew from 256 to (ready for this) 428 pages. That moby version is now
tucked away on <3scratch>RLL.KB.2 (unless the 3AM purger gets it.)
	So off I went to that <3SCRATCH> directory, deciding to do this
compacting with DRIBBLE's watchful eye looking on. The results are in
preserved in <CSD.IA>1DAVE and <CSD.IA>1DAVE.  You'll note that first
COPYBYTES, and then OPENF broke; the latter twice.  I might mention the
second run I got some TELNET error, and so had to ATtach that job.
	Any theories? All runs began with <CSD.LENAT>CORLL-DB.EXE.2.
Russ


13-Aug-80 20:41:59-PDT,535;000000000001
Mail-from: ARPANET site SU-AI rcvd at 13-Aug-80 2041-PDT
Date: 13 Aug 1980 2041-PDT
From: Russell Greiner <RDG at SU-AI>
Subject: CORLL Problems
To:   csd.smith at SU-SCORE, csd.lenat at SU-SCORE
CC:   csd.greiner at SU-SCORE  

Dave:
	Do you realize your functions do NOT run interpreted now?
(To see what became of UP-GETNETWORK, I enterred UP-PUTUNIT, and
did a GETD on something using a UP-GETUNITFIELD.)
	Also, would it be possible for INTTY (and friends) to accept
"]" gracefully, returning NIL?
	Thanks.
Russ


14-Aug-80 12:51:43-PDT,00000000152;000000000001
Date: 14 Aug 1980 1251-PDT
From: CSD.SMITH
Subject: bug
To: CSD.FREEMAN
cc: CSD.GREINER

The UA-DELVALUE bug you reported is now fixed.
-------
14-Aug-80 20:22:42-PDT,701;000000000001
Mail-from: ARPANET site SU-AI rcvd at 14-Aug-80 2022-PDT
Date: 14 Aug 1980 2022-PDT
From: Russell Greiner <RDG at SU-AI>
Subject: CORLL    
To:   csd.smith at SU-SCORE, csd.lenat at SU-SCORE
CC:   csd.greiner at SU-SCORE  

Dave
Yes, having ] would still be nice ... I still don't trust ↑E, and would prefer
to use them as seldom as possible.
The unworking function was UP-PUTUNIT. It is possible its difficulties
are due to RLL's syntactic sugar -- our FAULTEVAL may override
INTERLISP's original one; and it was that function actually expanded
the various macros.
Finally, I need a function mapping each unit into the name its KB.
(I think that's the only one I'll need.)
	Russ


 4-Sep-80 14:34:13-PDT,962;000000000001
Mail-from: ARPANET site SU-AI rcvd at 4-Sep-80 1434-PDT
Date: 04 Sep 1980 1433-PDT
From: Russell Greiner <RDG at SU-AI>
Subject: Re: CORLL Problems 
To:   csd.greiner at SU-SCORE    

 ∂14-Aug-80  1216	CSD.SMITH at SU-SCORE 	Re: CORLL Problems    
Date: 14 Aug 1980 1215-PDT
From: CSD.SMITH at SU-SCORE
Subject: Re: CORLL Problems
To: RDG at SU-AI
In-Reply-To: Your message of 13-Aug-80 2041-PDT

Why are you using UP-GETNETWORK anyway?  Don't use any UP- functions.  If 
you need something thats not provided, ask and we'll make or embelish a 
UA- function to fill the need.  All the UP- field accessing macros have been
consolidated into one UP-GETUNITFIELD.
	What functions no longer run interpretively?  They run slowly, but they
still should run.
	Making INTTY accept ] and return NIL can be done, but since ASKUSER is
ERRORSET protected control-E automatically serves that purpose now.  Do you 
still want the ]?

Dave
-------


22-Aug-80 11:03:52-PDT,00000212;000000000001
Date: 22 Aug 1980 1103-PDT
From: CSD.SMITH
Subject: UA-PUTVALUE
To: CSD.GREINER
cc: CSD.FREEMAN, CSD.LENAT

Have fixed the bug Russ found in UA-PUTVALUE.  New version of CORLL on CSD.RLL.

Dave
-------
22-Aug-80 12:00:32-PDT,0000000207;000000000001
Date: 22 Aug 1980 1200-PDT
From: CSD.GREINER
Subject: But but but
To: csd.smith
cc: csd.greiner

To the best of knowledge, UA-PUTVAUE worked ok;
it was UA-GETVALUE which didn't work.
	Russ
-------
23-Aug-80 12:18:35-PDT,00000000493;000000000001
Date: 23 Aug 1980 1218-PDT
From: CSD.SMITH
Subject: Re: But but but
To: CSD.GREINER
In-Reply-To: Your message of 22-Aug-80 1200-PDT

That's entirely possible.  The bug that I fixed affected all of the GET and 
PUT functions.  None of them were recognizing when a unit didn't exist.  I
couldn't get the bug to cause trouble in UA-GETVALUE but I did get it to show
itself in UA-PUTVALUE.  I didn't remember which one you'd found it in - but
it affected both of them.
	Dave.
-------
 4-Sep-80 14:45:14-PDT,1314;000000000001
Mail-from: ARPANET site SU-AI rcvd at 4-Sep-80 1445-PDT
Date: 04 Sep 1980 1444-PDT
From: Russell Greiner <RDG at SU-AI>
Subject: Re: CORLL
To:   csd.greiner at SU-SCORE    

 ∂15-Aug-80  1105	CSD.SMITH at SU-SCORE 	Re: CORLL        
Date: 15 Aug 1980 1059-PDT
From: CSD.SMITH at SU-SCORE
Subject: Re: CORLL    
To: RDG at SU-AI
In-Reply-To: Your message of 14-Aug-80 2022-PDT

The function you desire is provided by UA-UNIT? -- if the unit exists UA-UNIT?
returns its network.  While this handles the current need, it points out a 
problem that I have yet to solve -- The information contained in the fixed
fields for a unit is realy meta-information (ie: information about the 
representation) and should be obtainable by addressing the meta-node.  This
will call for some of the smarts of ANALOG since this information is 
represented in an entirely different fashion.  I have been putting some thought
into the matter but as yet don't have a clean and efficient solution to the
problem.
	I will look into the UA-PUTUNIT disturbance but I can't imagine why
it wouldn't wor correctly unless the macros are not getting expanded properly.
What kind of error do you get when attempting to run it interpretively?  Have
you tried running other functions interpretively?

Dave.
-------


24-Aug-80 01:55:40-PDT,000000226;000000000001
Date: 24 Aug 1980 0155-PDT
From: CSD.LENAT
Subject: UP-GETNETWORK
To: csd.smith
cc: csd.greiner, csd.lenat

occurs in UU-RETRIEVE. Also, I still can't get your varius macors to
run interpreted.
         Russ
-------
24-Aug-80 12:32:34-PDT,00000000284;000000000001
Date: 24 Aug 1980 1232-PDT
From: CSD.LENAT
Subject: COMMISSUE
To: csd.smith
cc: csd.greiner, csd.lenat

Has this function been renamed, or just deleted? (Doug & I had a program
which used it...)
   Russ
(BY the way, CORLL been behaving itself thus far, of course.)
-------
25-Aug-80 23:00:28-PDT,00000000743;000000000001
Date: 25 Aug 1980 2300-PDT
From: CSD.LENAT
Subject: Grumble...
To: csd.smith, csd.lenat
cc: csd.greiner

Dave - encountered a few problems recently:
1) The (CADR EURISKO) had the value 2092; and the last element of this
list was (...  . T)!  When I tried to close this KB, I got a UnitIndex
not on incorelist message, (... see a hacker). [See TRACEB.AUG25
for the context.]  Could this have been caused by Transfering units
into this KB?   This sysout began a day earlier, when that disk problem
was rampant; and in an earlier trace file you'll note a JSYS error,
at about the time it first reared its head.
   2nd: For some reason, AFTERSYSOUTFORMS, after working perfectly for
quite a while, 
Gotta go. More later.
-------
26-Aug-80 00:48:18-PDT,000000592;000000000001
Date: 26 Aug 1980 0048-PDT
From: CSD.LENAT
Subject: Grumble, con't
To: csd.smith, csd.lenat
cc: csd.greiner

(Sorry to leave so abruptly) At any event, after I editted AFTERSYSOUTFORMS
(actually, just examined it using EDITV), I did a SYSOUT, and then loaed
the *.EXE file; and found it broke -- that is, it tried to execute
the UP-GETPAGEFILE macro which occurs in the openning network procedure
in ASFs, and couldn't. I then changed that call into a function, which
is located in the file <CSD.LENAT>DAMN, which I then compiled.
   Could you have CORLL do this?
Russ
-------
26-Aug-80 13:26:59-PDT,000000238;000000000001
Date: 26 Aug 1980 1326-PDT
From: CSD.SMITH
Subject: Re: UP-GETNETWORK
To: CSD.LENAT
cc: csd.greiner
In-Reply-To: Your message of 24-Aug-80 0155-PDT

I will fix UU-RETRIEVE.  Tell me which macros don't run interpretively.
-------
26-Aug-80 13:30:01-PDT,000000378;000000000001
Date: 26 Aug 1980 1329-PDT
From: CSD.SMITH
Subject: Re: COMMISSUE
To: CSD.LENAT
cc: csd.greiner
In-Reply-To: Your message of 24-Aug-80 1232-PDT

The reason it disappeared is that there already exists an INTERLISP function
which does the same thing -- the function is called TENEX but works on TOPS20
as well as TENEX.  It is documented in the manual.
	Dave.
-------
27-Aug-80 01:04:24-PDT,000000815;000000000001
Date: 27 Aug 1980 0104-PDT
From: CSD.GREINER
Subject: Trouble!!
To: csd.lenat, csd.smith
cc: CSD.GREINER

Dave - It seems CORLL isn't doing the right things when openning files.
Somehow I had a SPILL.PAGE.2 (how is that ".2" possible?)
which had a unit which tried to read after the end of that file!
I then deleted that unit (which required some shenanigans, as I couldN't
read it in, ...) and the file was able to close ok. This SPILL kb was then
read in, and diagnosed; and seems sorta healthy.
    But.... After I rad them in, and did alot of things, such as Diagnosing,
2 of my 5 KBs did not have closed page files -- that is, I was unable
to see them using DIRECTORY; and their *.KB files were still open!
     I'll bring listings documenting all this nonesense, when I return.
Russ
-------
27-Aug-80 08:52:15-PDT,0000000835;000000000001
Date: 27 Aug 1980 0852-PDT
From: CSD.SMITH
Subject: Re: Trouble!!
To: CSD.GREINER
cc: csd.lenat
In-Reply-To: Your message of 27-Aug-80 0104-PDT

I suspect that confusion is the primary difficulty here.  Some facts that you
should know:

	1.  *.PAGE.2 or .3 or .4 etc. is quite normal.  Opening, closing, and 
	    reopening a knowledge base will result in this.  The name of the 
	    paging file is irrelevant to CORLL.

	2.  When a network is opened for read only, no paging file is created
	    and the .KB file is used (but opened for input only).

	3.  UF-CREATENETWORK does not open, close and reopen a new paging file
	    so the paging file will not show up with a DIR.  The CPAGE opened
	    by UU-COMPACT will also not be visible.

Insufficient data to investigate your spill problem.

Dave.
-------
27-Aug-80 09:33:52-PDT,0000787;000000000001
Date: 27 Aug 1980 0933-PDT
From: CSD.SMITH
Subject: Macros
To: CSD.LENAT, CSD.GREINER

I have been unable to reproduce your macro problems.  The problem (whatever it
is) appears to have nothing to do with FAULTAPPLY and FAULTEVAL since MACROTRAN
does its stuff before these two ever get called.  I have tried several macros
(with UTIL and RLL present) and they work fine.  I have also made sysouts and
reenterred them without difficulty.  One unfortunate side effect of the fact 
that MACROTRAN is invoked before FAULT* is that macros cannot be called from
the top level using the  "macroname(arguments)" form but must be called as
"(macroname 'arguments)".  This is only a minor inconvenience, however.  Make
me a sysout in which a macro "doesn't work".

Dave.
-------
27-Aug-80 18:11:40-PDT,0000001051;000000000001
Date: 27 Aug 1980 1811-PDT
From: CSD.GREINER
Subject: Bugs and more bugs...
To: csd.smith, csd.lenat
cc: CSD.GREINER

Dave - after working beautifully for several days, I now find myself 
encountering a slew of CORLL problems.
The first stems from UA-GETVALUES  -- it never checks that its
arg is a unit, and hence returns nonNIL on any list! What's more, it feels
free to overwrite the value of that atom.
  Second - I figured the problem I tried to describe to you last night:
Unbeknownst to me (at that time) those two KBs were being openned in readonly
mode, due to an incompatibility in the new UF-OPENNETWORK
from the previous one (or rather, from my version of that.)
A side comment: In StandardInit, you never give the user the option
of openning another dependent KB in, say, read only mode (when you map thru
those kbs...
  It would also be nice if CORLL probided a function which put a KB which had
been in readonly mode, readwrite.
   There have been a few other problems, but I'll save thse for later.
Russ
-------
 4-Sep-80 17:56:06-PDT,0000517;000000000001
Date:  4 Sep 1980 1756-PDT
From: CSD.LENAT
Subject: CLOSED TEMP
To: CSD.GREINER
cc: CSD.SMITH

I closed and archived TEMP, after CLOSEing all the kbs; they all
diagnosed OK.  See TRACE.SEP04 for details if you need to.
The TEMP sysout did not load right; I had to OPENFILE every .PAGE
file by hand!  I think this is the result of Russ's monkeying with
AFTERSYSOUTFORMS, and hopefully was a transient which will go away by
(i) using Dave's new CORLL, (ii) not using the DAMN file anymore.

Doug
-------
 9-Nov-80 12:08:39-PST,00000349;000000000001
Date:  9 Nov 1980 1208-PST
From: CSD.GREINER
Subject: WHENCLOSE
To: csd.smith
cc: csd.greiner

... doesn't seem to be working.  When I return from a sysout, it tells me
it can't open my RLL.PAGE file.  Just before that, it tells me it was trying
to open a file named "NOBIND" - so somebody somewhere is clearly confused...

Russ
-------
15-Nov-80 18:55:42-PST,992;000000000001
Mail-from: ARPANET site PARC-MAXC2 rcvd at 15-Nov-80 1855-PST
Date: 14 NOV 1980 1656-PST
From: STEFIK at PARC-MAXC2
Subject: MRS bug isolated
To:   csd.smith at SCORE, csd.greiner at SCORE,
To:   csd.berlin at SCORE
cc:   stefik

Dave,
	We found a trace of the events leading to the bad call to GETTOPVAL --
the problem is that GETTOPVAL is called on a List, not an atom.  It is
called in the following example -- we denote by L the list

(MyToAssert (a b c))

In side

	UP-GETUNITINFO (L)

	UP-REFERENCE (     which calls (UP-INCORE? (L

	(UA-GET L)

	(UR-MATCHFACTS  which calls (UA-GET L)

	(UR-MATCHES (Pattern Matcher)

		where Pattern = (SubClass L ?x)

		it bombs in the MAPCONC on the 2nd iteration

All of this being started by the function

	(Assert '(a b c]


-----------
	We did a check and UR-Datum was called nowheres in this sequence
(we traced it).  UR-Datum is called only by UR-TrueP, UR-UnAssert
and UR-Put.  Danny & Mark

-------
24-Nov-80 20:19:00-PST,0000000232;000000000001
Date: 24 Nov 1980 2018-PST
From: CSD.GREINER
Subject: Infinite loop
To: csd.smith
cc: csd.greiner

That problem I mentioned a while back - where UP-BUMP effectively called UP-PUT
which called UP-BUMP which ....	
	
-------
24-Nov-80 20:26:26-PST,0000000706;000000000001
Date: 24 Nov 1980 2026-PST
From: CSD.GREINER
Subject: (continuation)
To: csd.smith
cc: csd.greiner

[Damn this TELENET connection - misinterpreting characters as CRs]
Well, it happened again this afternoon.  I tried reaching you during
the day, unsuccessfully...  Anyway, there is a SYSOUT, "<3SCRATCH>HAL.EXE"
which houses the state before this trouble erupted, and "<CSD.IA>TEMP.EXE"
which is the 

which contains the arbitrarily large stack, still in the break package.
In between is <CSD.IA>TRACE?.NOV24.  Note I've loaded in <LISPUSERS>EMACS.COM,
so enterring any EDITx calls an inferior fork's EMACS editor.
Shall I save the earlier HAL sysout (and accompanying *.PAGE files)
-------
24-Nov-80 20:33:04-PST,00000000795;000000000001
Date: 24 Nov 1980 2033-PST
From: CSD.GREINER
Subject: (and on and on)
To: csd.smith
cc: CSD.GREINER

[This is the last time I telnet from SAIL - damn those <ESCAPE>s]
from their respecit


from their untimely deaths at 3AM?
d
Thinking about PSETQ it occurs to me there's no real harm in giving it only
2 args (with one more optional) - where Arg#1 is the list of variables,

#2 list of values, and 3rd is list for temporary storage.  If I can get around
that infinite loop I'll implement that.

How was Jan's concert? (I've been doing things each of the last 4 evenings,

and have plans for each of the next 6 nights...  Had I known about this 
earlier I could have psyched myself up for it, and would definately have
attended...)

(This is really the end.)
Russ
-------
26-Nov-80 11:15:42-PST,00000000734;000000000001
Date: 26 Nov 1980 1115-PST
From: CSD.GREINER
Subject: I think I found the bug...
To: CSD.SMITH
cc: CSD.GREINER

It's now apparent that mess was of my own construction: I went ahead
and advised UP-PUT, as I had done to UP-PUTUNIT earlier - to tell me
when I was about to PUT the first unit.  After doing the necessary work,
this advice's last instruction is to remove itself.  Well, examining
the two TRACE files shows the command immediately prior to that apparently
infinite loop was that removal command...  But this used to work.
Do you think maybe block compiling was the difference?
Anyway, I'll try to hack around this; and will let you know what I
come up with.  Thanks for your help last night.
	Russ
-------
27-Nov-80 15:40:47-PST,00000897;000000000001
Date: 27 Nov 1980 1540-PST
From: CSD.GREINER
Subject: UP-NOBUMP, and friends
To: csd.smith
cc: CSD.GREINER

Remember that "UNDEFINED function" problem which used to happen when I
ran some of your code interpreted, when a macro was encountered? Well,
I'm getting the same problems again... Even with your compiled code.
The most numerous problems occur with UP-NOBUMP, although UP-WRITETRACE
has reared its head as well...  I've been editing your functions, and GETDing
the critical areas.  Interesting to note that the first level, eg the
UP-SETFILE... macros must have expanded appropriately; but the compiler
apparently never bothered going on, recursively, one other layer.
Is it possible UP-NOBUMP wasn't in the environment when you compiled
these functions, or, somehow, incorrectly declared?   I'll leave the
dribble files around for your inspection.
	Ciao,
Russ
-------
28-Nov-80 16:33:03-PST,0000001633;000000000001
Date: 28 Nov 1980 1633-PST
From: CSD.GREINER
Subject: Troubles
To: csd.smith
cc: CSD.GREINER, CSD.PURDY

UA-DELete, didn't.  That function called PUTHASHFILE with a second argument
of NIL, which PHF didn't catch. (According to the INTERLISP manual, this
should achieve the desired effect of deleting that unit.)  Anyway, I fixed
that function (see <CSD.IA>HASH, if I both MAKEFILEing it). 
Of course, there are problems even when this happens: There are times when
I'm in the process of creating/initializing a unit, when that unit needs to
be bumped - as it doesn't have any value, it simply gets deleted.
Soln: (1) Make UP-PUT a bit smarter - so it handles this case correctly (eg
put the value (NAME <name of the unit>) in leiu of NIL, or (2) just not PUT
such vacuous units.

Did you expunge QUOTE? ?  Please, in the future, leave such obsolete things
around for a while, with a warning injected in their beginning - urging the
user to begin considerin suggestion.
-------
14-Jan-81 21:47:36-PST,0000965;000000000001
Date: 14 Jan 1981 2147-PST
From: CSD.GREINER
Subject: Misc problems
To: csd.smith
cc: CSD.GREINER, CSD.PEAIRS

CORLL is pretty much behaving itself - jut a few minor bugs:
1) UA-LIST() don't work -- you have (LIST NIL) in the code, where
	I assume you meant (APPEND UF.NETWORKS)   <or just UF.NETWORKS>
2) There is a WRITE statement in UE-ASKNEWUNIT - which should be a WRITELNTTY.

A question about those UE-ASK... functions: is there someway of aborting them?
Typing ↑H, followed by an S-expr, sorta works, but leaves you a funny mode,
echo-wise.  ↑B is too drastic.  How about some funny symbol, like +, meaning
break ASAP, but not earlier?

Next: I still don't quite understand SPECVARS: 
Consider
(DEFINEQ (FOO (a b) (APPLY* (FUNCTION (LAMBDA (c) (PLUS c a))) 3)))
Now I assume "a" is a SPECVARS in this  ↑↑ internal function.
The question is, what should it be declared in FOO - as LOCAL or SPEC?

That's all for now.
   Russ
-------
15-Jan-81 15:32:53-PST,000000506;000000000001
Date: 15 Jan 1981 1532-PST
From: CSD.GREINER
Subject: CORLL Fixes
To: CSD.PEAIRS
cc: csd.greinER, CSD.SMITH

Are you now the official CORLL maintainer?  I've found two small bugs,
which Dave suggested you should examine:
1) The function, UE-ASKUNIT currently calls UA-LIST with the argument NIL.
	It should use the argument T.
2) UE-ASKNEWUNIT calls the function WRITE, which has been replaced with
	WRITELNTTY.
Both of these functions are in CORLLINIT, on <CSD.RLL>.
	Thanks,
Russ
-------
18-Jan-81 17:09:02-PST,00000000548;000000000001
Date: 18 Jan 1981 1709-PST
From: CSD.GREINER
Subject: CORLL updates
To: CSD.PEAIRS
cc: csd.smith, CSD.GREINER

Those changes to CORLL & CORLLUTIL have been made.  Dave - they're now
residing on CSD.RLL, rather than CSD.SMITH.  Feel free to move them, if
the mood hits you.

For what it's worth, I encountered a very strange OPNJFN problem, whilst
compiling another file (<CSD.RLL>UTIL.), which forced me to re-recompile
the file.  The resulting caveat is to be sure NOT to do an expunge during
a compilation; maybe.

	Russ
-------
15-May-81 16:13:32-PDT,11977;000000000000
Date:  7 May 1981 1234-PDT
From: GREINER
Subject: Unalterred DRIBBLE file
To: CSD.SMITH at SU-SCORE
cc: GREINER

 ***  Am opening Dribble file: <GREINER.RLL>TRACEA.MAY06.1 [ 6-May-81 22:54:08]
Shall I open the tracefile, BUMP.May06? no
Leaving UP.TRACEFILE as NIL.
The following KBs will now be opened: (<GREINER.RLL>RATALE.PAGE.1 
<GREINER.RLL>USERS.PAGE.1 <GREINER.RLL>SLOTS.PAGE.1 <GREINER.RLL>LISPFNS.PAGE.1 
<GREINER.RLL>RLL.PAGE.1)


Copied the network <GREINER.RLL>RATALE.PAGE.1 onto <CORE>RATALE.PAGE-RUSS.


Copied the network <GREINER.RLL>USERS.PAGE.1 onto <CORE>USERS.PAGE-RUSS.


Copied the network <GREINER.RLL>SLOTS.PAGE.1 onto <CORE>SLOTS.PAGE-RUSS.


Copied the network <GREINER.RLL>LISPFNS.PAGE.1 onto <CORE>LISPFNS.PAGE-RUSS.


Copied the network <GREINER.RLL>RLL.PAGE.1 onto <CORE>RLL.PAGE-RUSS.
NIL
84←NewKB]
Name of Knowledge Base? BBIKE
Opening knowledge base <GREINER.RLL>BIKE.PAGE.1
=<GREINER.RLL>BIKE.PAGE.1
You are about to write on an external file.
So far, this core image has been used by (GREINER).
Do you want to enter ReadOnly mode? no
UP-PUTB0027 will not be saved.

collecting lists
19150, 19150 free cells, 7 pages left

collecting atom name characters
848, 848 free cells, 7 pages left


   *****   In Starring:FnForUpdating.   ***** 
Break?  no

collecting lists
16299, 16299 free cells, 7 pages left
Must be a new file.  Proceed.

Just to play it safe, I'll now close the neonatal BIKE
 network,
and then reopen it.

Closing knowledge base <GREINER.RLL>BIKE.KB.2
Knowledge Base <GREINER.RLL>BIKE.KB.2 written by GREINER on  6-May-81 22:55:42
Opening knowledge base <GREINER.RLL>BIKE.KB.2
Last read NIL
Last written  6-May-81 22:55:42
Copying from <GREINER.RLL>BIKE.KB.2 to <GREINER.RLL>BIKE.PAGE.1.


Last written by (GREINER  6-May-81 22:55:41)
BIKE
85←UA-LIST(BIKE.PAGE]
NIL
86←(CAR UF.NETWROKS]
u.b.a.
UF.NETWROKS

87←UF.NETWORKS
(<GREINER.RLL>BIKE.PAGE.1 <GREINER.RLL>RATALE.PAGE.1 <GREINER.RLL>USERS.PAGE.1 
  <GREINER.RLL>SLOTS.PAGE.1 <GREINER.RLL>LISPFNS.PAGE.1 <GREINER.RLL>RLL.PAGE.1)
88←(UA-LIST (CAR UF.NETWORKS]
(BIKE.STATUS FREEBLOCKINDEX UNITINDEX)
89←EU BIKE.STATUS
edit
37*p
(Isa (AnyStatus) OrderedPrototypes (TypicalStatus TypicalConcreteThing 
TypicalThing) MyCreatedAs (IExamples &) MyTimeOfCreation " 6-May-81 22:55:09" 
MyCreator "GREINER" AllIsas (AnyStatus AnyOverhead AnyConcreteThing Anything) 
Networks (RLL) WhenWritingNetwork StandardFinishUp KBsFNS (BIKEFNS) LoadFiles (
BIKE) --)
37*f New≠

New≠  ?
38*f Net≠
=Networks
39*2 p
(RLL)
40*(n RATALE]
41*↑ w
... WhenOpeningNetwork StandardStartUp NetworkStatus ("GREINER" 
" 6-May-81 22:55:41") OpenDate " 6-May-81 22:55:45" KBsConnectedTo (BIKE.STATUS 
RLL.STATUS) KBsVARS (BIKEVARS) MySensibleSlots (Specializations 
OrderedPrototypes Isa AllIsas AllGenls AllSpecs Prototypes Characteristics Descr
 MyCreator MyTimeOfCreation MyToKillMe MyToRenameMe MyEssentialVirtualSlots 
MySlotsNowOrdered MySensibleSlots MyCreatedAs MySlots KBsVARS --))
43*ok
Verifying slots
BIKE.STATUS
90←

90←UF.NETWORKS
(<GREINER.RLL>BIKE.PAGE.1 <GREINER.RLL>RATALE.PAGE.1 <GREINER.RLL>USERS.PAGE.1 
  <GREINER.RLL>SLOTS.PAGE.1 <GREINER.RLL>LISPFNS.PAGE.1 <GREINER.RLL>RLL.PAGE.1)
91←(UF-WRITE (CAR UF.NETWORKS]
Closing knowledge base <GREINER.RLL>BIKE.PAGE.1
Knowledge Base <GREINER.RLL>BIKE.PAGE.1 written by GREINER on  6-May-81 22:57:59
<GREINER.RLL>BIKE.PAGE.1
92←

92←EXEC
131075
93←UF-OPEN(BIKE.PAGE.2 BOTH]
Opening knowledge base <GREINER.RLL>BIKE.PAGE.2
Last read NIL
Last written  6-May-81 22:49:31

collecting atom name characters
744, 744 free cells, 7 pages left

collecting atoms
0, 170 free cells, 5 pages left

collecting atom name characters
22, 534 free cells, 3 pages left
<GREINER.RLL>BIKE.PAGE.2
94←UF-OPEN(BIKE.PAGE.1]
Opening knowledge base <GREINER.RLL>BIKE.PAGE.1
Last read  6-May-81 23:00:29
Last written  6-May-81 22:55:45
<GREINER.RLL>BIKE.PAGE.1
95←(UA-LIST '<GREINER.RLL>BIKE.PAGE.1]
(FREEBLOCKINDEX UNITINDEX BIKE.STATUS)
96←(UA-TRANSFER 'BIKE.STATUS '<CSD.GREINER>BIKE.PAGE.2]
NIL
97←fix
edit
44*e (UA-KB? 'BIKE.STATUS]
<GREINER.RLL>BIKE.PAGE.1
 ***  Am re-opening Dribble file: <GREINER.RLL>TRACEA.MAY06.1 [
 6-May-81 23:04:23]
44*RC CSD.G G
<CSD.GREINER>BIKE.PAGE.2-><GREINER>BIKE.PAGE.2
45*RC ER ER.RLL
UA-TRANSFER->UA-TRANSFER.RLL
<GREINER>BIKE.PAGE.2-><GREINER.RLL>BIKE.PAGE.2
46*undo
RC undone.
47*p
(UA-TRANSFER (QUOTE BIKE.STATUS) (QUOTE <GREINER>BIKE.PAGE.2))
47*3 redo RC
<GREINER>BIKE.PAGE.2-><GREINER.RLL>BIKE.PAGE.2
49*ok
BIKE.STATUS
99←redo UA-KB?
<GREINER.RLL>BIKE.PAGE.1
100←UA-KB?(BIKE.STATUS]
<GREINER.RLL>BIKE.PAGE.1
1←BIKE.PSTATUS
u.b.a.
BIKE.PSTATUS

2←BIKE.STATUS
((<GREINER.RLL>BIKE.PAGE.1 . BIKE.STATUS)
 1604
 (Isa (AnyStatus)
      OrderedPrototypes
      (TypicalStatus TypicalConcreteThing TypicalThing)
      MyCreatedAs
      (IExamples (AnyStatus))
      MyTimeOfCreation " 6-May-81 22:55:09" MyCreator "GREINER" AllIsas
      (AnyStatus AnyOverhead AnyConcreteThing Anything)
      Networks
      (RLL RATALE)
      WhenWritingNetwork StandardFinishUp KBsFNS (BIKEFNS)
      LoadFiles
      (BIKE)
      WhenOpeningNetwork StandardStartUp NetworkStatus ("GREINER" 
                                                       " 6-May-81 22:55:41")
      OpenDate " 6-May-81 22:55:45" KBsConnectedTo (BIKE.STATUS RLL.STATUS)
      KBsVARS
      (BIKEVARS)
      MySensibleSlots
      (Specializations OrderedPrototypes Isa AllIsas AllGenls AllSpecs 
                       Prototypes Characteristics Descr MyCreator 
                       MyTimeOfCreation MyToKillMe MyToRenameMe 
                       MyEssen

3←fix UA-TRAN≠
=UA-TRANSFER
edit
50*p
(UA-TRANSFER (QUOTE BIKE.STATUS) (QUOTE <GREINER.RLL>BIKE.PAGE.2))
50*e UF.NETWORKS
(<GREINER.RLL>BIKE.PAGE.1 <GREINER.RLL>BIKE.PAGE.2 <GREINER.RLL>RATALE.PAGE.1 
  <GREINER.RLL>USERS.PAGE.1 <GREINER.RLL>SLOTS.PAGE.1 
  <GREINER.RLL>LISPFNS.PAGE.1 <GREINER.RLL>RLL.PAGE.1)
50*3 2 EP
edit
51*p
(UNITINDEX (& & & & & & & & & & & & & & & & & & & --) FREEBLOCKINDEX (&) 
FILEHANDLE <GREINER.RLL>BIKE.PAGE.2 ACCESS BOTH STATUSFN HASHSTATUS)
51*ok
<GREINER.RLL>BIKE.PAGE.2
52*ok
BIKE.STATUS
6←(UA-KB? 'BIKE.STATUS]
<GREINER.RLL>BIKE.PAGE.1
7←UF-CANCEL(<GREINER.RLL>BIKE.PAGE.1]
Closing knowledge base <GREINER.RLL>BIKE.PAGE.1
(<GREINER.RLL>BIKE.PAGE.1)
8←EXEC
131075
9←(UF-OPEN 'TEMP]
Knowledge base TEMP doesn't exist.
NIL
10←(UF-OPEN 'TEMP.PAGE.1]
Opening knowledge base <GREINER.RLL>TEMP.PAGE.1
Last read  6-May-81 23:02:46
Last written  6-May-81 22:55:45
<GREINER.RLL>TEMP.PAGE.1
11←fix UA-TR≠
=UA-TRANSFER
edit
53*p
(UA-TRANSFER (QUOTE BIKE.STATUS) (QUOTE <GREINER.RLL>BIKE.PAGE.2))
53*ok
BIKE.STATUS
 ***  Am re-opening Dribble file: <GREINER.RLL>TRACEA.MAY06.1 [
 6-May-81 23:08:33]
12←BIKE.STATUS
((<GREINER.RLL>TEMP.PAGE.1 . BIKE.STATUS)
 1611
 (Isa (AnyStatus)
      OrderedPrototypes
      (TypicalStatus TypicalConcreteThing TypicalThing)
      MyCreatedAs
      (IExamples (AnyStatus))
      MyTimeOfCreation " 6-May-81 22:55:09" MyCreator "GREINER" AllIsas
      (AnyStatus AnyOverhead AnyConcreteThing Anything)
      Networks
      (RLL RATALE)
      WhenWritingNetwork StandardFinishUp KBsFNS (BIKEFNS)
      LoadFiles
      (BIKE)
      WhenOpeningNetwork StandardStartUp NetworkStatus ("GREINER" 
                                                       " 6-May-81 22:55:41")
      OpenDate " 6-May-81 22:55:45" KBsConnectedTo (BIKE.STATUS RLL.STATUS)
      KBsVARS
      (BIKEVARS)
      MySensibleSlots
      (Specializations OrderedPrototypes Isa AllIsas AllGenls AllSpecs 
                       Prototypes Characteristics Descr MyCreator 
                       MyTimeOfCreation MyToKillMe MyToRenameMe 
                       MyE

13←UA-KB?(BIKE.STATUS]
<GREINER.RLL>TEMP.PAGE.1
14←SMARTARGLIST(UA-TRANSFER]
($$UNITNAME $$NEWKB $$UNIT)
15←USE PP
****can't find <CSD.RLL>CORLL..304
loading from <CORE>CORLL..3

(UA-TRANSFER
  [LAMBDA ($$UNITNAME $$NEWKB $$UNIT)  **COMMENT**  
    (DECLARE (LOCALVARS $$UNITNAME $$NEWKB $$UNIT))
    (COND
      ((FMEMB $$NEWKB UF.NETWORKS)
        (SETQ $$UNIT (UA-GET $$UNITNAME))
        (UA-DEL $$UNITNAME)
        (UA-ADD $$NEWKB $$UNITNAME)
        (UA-PUT $$UNITNAME $$UNIT)
        $$UNITNAME])
(UA-TRANSFER)
16←(SETQ aa (UA-GET 'BIKE.STATUS]
(Isa (AnyStatus)
     OrderedPrototypes
     (TypicalStatus TypicalConcreteThing TypicalThing)
     MyCreatedAs
     (IExamples (AnyStatus))
     MyTimeOfCreation " 6-May-81 22:55:09" MyCreator "GREINER" AllIsas
     (AnyStatus AnyOverhead AnyConcreteThing Anything)
     Networks
     (RLL RATALE)
     WhenWritingNetwork StandardFinishUp KBsFNS (BIKEFNS)
     LoadFiles
     (BIKE)
     WhenOpeningNetwork StandardStartUp NetworkStatus ("GREINER" 
                                                       " 6-May-81 22:55:41")
     OpenDate " 6-May-81 22:55:45" KBsConnectedTo (BIKE.STATUS RLL.STATUS)
     KBsVARS
     (BIKEVARS)
     MySensibleSlots
     (Specializations OrderedPrototypes Isa AllIsas AllGenls AllSpecs 
                      Prototypes Characteristics Descr MyCreator 
                      MyTimeOfCreation MyToKillMe MyToRenameMe 
                      MyEssentialVirtualSlots MySlotsNowOrdered MySensibleSlots 
                      MyCreatedAs MySlots KBsVARS KBsConnectedTo OpenDate 
                      NetworkStatus WhenOpeningNetwork LoadFiles KBsFNS 
                      WhenWritingNetwork Networks DependentNetworks Network*))
17←UF-CANCEL(TEMP.PAGE.1]
=<GREINER.RLL>TEMP.PAGE.1
Closing knowledge base <GREINER.RLL>TEMP.PAGE.1
(<GREINER.RLL>TEMP.PAGE.1)
18←(UA-ADD 'BIKE.PAGE.2 'BIKE.STATUS]
BIKE.STATUS
19←fix
edit
54*p
(UA-ADD (QUOTE BIKE.PAGE.2) (QUOTE BIKE.STATUS))
54*(1 UA-PUT]
55*(2)
56*(n (COPY aa]
57*ok
((Isa (AnyStatus)
      OrderedPrototypes
      (TypicalStatus TypicalConcreteThing TypicalThing)
      MyCreatedAs
      (IExamples (AnyStatus))
      MyTimeOfCreation " 6-May-81 22:55:09" MyCreator "GREINER" AllIsas
      (AnyStatus AnyOverhead AnyConcreteThing Anything)
      Networks
      (RLL RATALE)
      WhenWritingNetwork StandardFinishUp KBsFNS (BIKEFNS)
      LoadFiles
      (BIKE)
      WhenOpeningNetwork StandardStartUp NetworkStatus ("GREINER" 
                                                       " 6-May-81 22:55:41")
      OpenDate " 6-May-81 22:55:45" KBsConnectedTo (BIKE.STATUS RLL.STATUS)
      KBsVARS
      (BIKEVARS)
      MySensibleSlots
      (Specializations OrderedPrototypes Isa AllIsas AllGenls AllSpecs 
                       Prototypes Characteristics Descr MyCreator 
                       MyTimeOfCreation MyToKillMe MyToRenameMe 
                       MyEssentialVirtualSlots MySlotsNowOrdered 
                       MySensibleSlots MyCreatedAs MySlots KBsVARS 
                       KBsConnectedTo OpenDate NetworkStatus WhenOpeningNetwork 
                       LoadFiles KBsFNS WhenWritingNetwork Networks 
                       DependentNetworks Network*)) . T)
20←EU BIKE.STATUS
edit
58*p
(Isa (AnyStatus) OrderedPrototypes (TypicalStatus TypicalConcreteThing 
TypicalThing) MyCreatedAs (IExamples &) MyTimeOfCreation " 6-May-81 22:55:09" 
MyCreator "GREINER" AllIsas (AnyStatus AnyOverhead AnyConcreteThing Anything) 
Networks (RLL RATALE) WhenWritingNetwork StandardFinishUp KBsFNS (BIKEFNS) 
LoadFiles (BIKE) --)
58*ok
Nothing changed.
BIKE.STATUS
21←UF.NETWORKS
(<GREINER.RLL>BIKE.PAGE.2 <GREINER.RLL>RATALE.PAGE.1 <GREINER.RLL>USERS.PAGE.1 
  <GREINER.RLL>SLOTS.PAGE.1 <GREINER.RLL>LISPFNS.PAGE.1 <GREINER.RLL>RLL.PAGE.1)
22←INFO DIS


T
23←EXEC
131075
24←SOS RUSS
Bye now.
It is now  6-May-81 23:14:26.
Closing DribbleFile <GREINER.RLL>TRACEA.MAY06.1
-------
                ---------------
-------
15-May-81 16:13:44-PDT,570;000000000000
Mail from SU-SCORE rcvd at 7-May-81 1324-PDT
Date:  7 May 1981 1328-PDT
From: CSD.SMITH at SU-SCORE
Subject: Re: Unalterred DRIBBLE file
To: GREINER at RAND-AI
In-Reply-To: Your message of 7-May-81 1235-PDT

I understand now.  If a KB isn't open for read/write you can't delete a unit
from it, thus UA-ADD fails because there already is a unit by that name in a
read only KB.  I'll fix UA-ADD so that you can add a unit of the same name to
a different KB.  I'll have it print a warning message in this case.
-------
                ---------------
-------
 7-May-81 12:11:33-PDT,00000711;000000000001
Date:  7 May 1981 1211-PDT
From: CSD.GREINER
Subject: CORLL Trouble
To: csd.smith
cc: CSD.GREINER

Two bugs found:
1) UA-ASKNEWUNIT labors under the impression that UA-UNIT? is a function;
	and blows up.  I haven't tested the other ASKing functions; someone
	should...
2) UA-TRANSFER doesn't work, and fails in the worst possible way: Although
	it returns the unit's name, that unit is NOT transfered into a new KB!
   A general suggestion: In this, and other places, using
(AND f1 f2 f3 ... $$UNITNAME)
	or (COND (f1 (AND f2 f3 ... $$UNITNAME)))
would be preferable to the current
(COND (f1 f2 f3 ... $$UNITNAME))

That's all for now.
Thanks,
	Russ                ---------------
-------
 7-May-81 13:14:45-PDT,000000766;000000000001
Date:  7 May 1981 1314-PDT
From: CSD.SMITH
Subject: CORLL
To: CSD.GREINER

It turns out to be reasonably difficult to put in "SillyRussFlg".  How about
if I instead make two global system parameters called UA.AUTOADDFLG and UA.AUTO
DELFLG which can be reset as desired.

I don't understand what the problem is with UA-TRANSFER.  Seems to work fine
for me.

How often do you and Doug transfer KB's from dolphins to SCORE?  Would you
object violently to having to use the XWRITE format when transferring between
these two machines?  If not then I may let SCORE's CORLL use the real HASHFILE
package.

I'm adding a (SETQ MKSWAPSIZE 1) into my init file so that all compiled code
goes into shadow space.  You may want to do the same for RLL.
-------
 2-Jun-81 15:20:35-PDT,000000607;000000000001
Date:  2 Jun 1981 1520-PDT
From: CSD.GREINER
Subject: Incompatible changes
To: csd.smith
cc: CSD.GREINER

Dave -
	I'm a small slew of old KBs which I was about to convert to Xfiles,
for more permanent storage.  I can't seem to do this, though.  Have you make
any recent (ie last 3-4 months) which would cause the files to now longer
be in the correct format?  (See the *.OLDKB files on <CSD.RLL>.)
Can we recover their contents?  (When this happened earlier, with GENLINFO,
I EMACS'ed that file into a Xfile, and proceeded from there.  I'd rather
not have to do this again...)
	Russ
-------
13-Jun-81 17:21:43-PDT,1678;000000000001
Mail-from: ARPANET site RAND-AI rcvd at 13-Jun-81 1721-PDT
Date: 13 Jun 1981 1704-PDT
From: GREINER at RAND-AI
Subject: Grumbles, for posterity
To: csd.smith at SU-SCORE
cc: csd.greiner at SU-SCORE

Troubles with CORLL/HASH:

1. During a long session, I
 (i)   performed a slew of updates to bunches of units,
 (ii)  had them all bumped all out,
 (iii) read many of them back in,
 (iv)  performed yet even more modifications
 (v)   and finally, wrote and closed the involved KBs.
When they were read back in, (step iii), they seemed ok --
I'm sure I would have noticed if any were seriously off.
BUT....
When I reopened these KBs, (after v), several of them were wrong -
their values were what they been BEFORE this whole session began!
(This included the "TransitiveSCFormer" unit, on which most of my efforts
had been devoted.)  Very annoying!
Other units had the correct, updated values.  Very puzzling!
Ideas?

2. On that next session, I had troubles with "--"s:
Various units had their first 10 pairs of properties/values ok, but
their "plist" ended with a "--" -- apparently the printlevel was not
so good.  Other units were totally alright.
Perhaps this was because the bump had occurred during a PrettyPrint,
and that had caused (PRINTLEVEL) to be mis-set?  But, but, but:
the manual tells us that print leve is NOT used when printing onto
external files, except when PLVLFILEFLG is T; and, I just checked, as
of now it ain't!  Q: Are HASH files considered external files?  (How
could they not be?)

Anyway, I'll keep trying to track down the problems... I knew we should
just have stayed with your package, Dave...
	Russ
-------
14-Jun-81 14:10:47-PDT,00000436;000000000001
Date: 14 Jun 1981 1410-PDT
From: CSD.DEA (Doug Appelt)
Subject: Re: [GREINER at RAND-AI: Grumbles, for posterity]
To: CSD.GREINER
In-Reply-To: Your message of 13-Jun-81 2351-PDT

	Beats me.  Are you sure that PRETTYPRINT is actually responsible for
the printing?  LISP internal routines should never change the printlevel
except under a RESETLST, so I would guess that your code is somewhere to blame.

						- Doug
-------
15-Jun-81 12:09:31-PDT,780;000000000001
Mail-from: ARPANET site SU-AI rcvd at 15-Jun-81 1209-PDT
Date: 15 Jun 1981 1208-PDT
From: Russell Greiner <RDG at SU-AI>
Subject: Hash File Problem #2 - "--"  
To:   csd.smith at SU-SCORE, csd.vanmelle at SU-SCORE
CC:   csd.greiner at SU-SCORE    

Dave -
	This is to repeat the message I phoned to you last Saturday:
Several of the units which were written into the RLL.PAGE hash file
appeared to have been printed there with some inappropriate value for
(PRINTLEVEL) -- these units were littered with "--"s everywhere!
(well, whenever the CAR-depth + CDR-depth exceeded some value.)

[Bill - this was done at Rand-Ai, but using the good hash package -
<LISPUSERS>HASH.COM;12.  I can send you a dribble file, showing the
clobberage, if you wish...]

	Russ


15-Jun-81 22:09:01-PDT,979;000000000001
Mail-from: ARPANET site PARC-MAXC rcvd at 15-Jun-81 2208-PDT
Date: 15 Jun 1981 22:08 PDT
From: vanMelle at PARC-MAXC
Subject: Re: problem with enormous hashfiles
In-reply-to: CSD.GREINER's message of 15 Jun 1981 1201-PDT
To: CSD.GREINER at SU-SCORE
cc: Masinter, csd.dea at SU-SCORE, csd.smith at SU-SCORE, vanMelle, Kaplan

I did what you described and found that you were calling CREATEHASHFILE
with ITEMLENGTH=512 and #ENTRIES=1000.  An itemlength of 512 is absurd. 
This is the length of the KEYS, remember, not the values (at least for EXPR
files).  Given that you said you wanted 1000 entries with an average
keylength of 512, you're talking about a file that takes over 200 pages
just to store the keys, even if all the values are null!  So I think it
was rather polite in only preallocating 130 pages.

I don't know why older versions of HASH made smaller files; presumably Ron
changed the code to make "better" use of ITEMLENGTH and #ENTRIES.

	Bill
15-Jun-81 22:16:54-PDT,911;000000000001
Mail-from: ARPANET site PARC-MAXC rcvd at 15-Jun-81 2216-PDT
Date: 15 Jun 1981 22:16 PDT
From: vanMelle at PARC-MAXC
Subject: PLVLFILEFLG
To: CSD.GREINER at SU-SCORE
cc: vanMelle

The behavior you described is certainly consistent with PLVLFILEFLG being
true.  There are, however, only a very few places in the system that this flag is
deliberately made non-NIL: when printing a backtrace, when doing a ?= in the
break package, and inside of COMPARELISTS.  So the only way I can imagine
you'd get this way is if you evaluated something with a ?= that caused someone
to do a PUTHASHFILE.

So HASH should probably resetvar PLVLFILEFLG to NIL.  Meanwhile, you could
(a) advise(PUTHASHFILE AROUND (RESETVARS (PLVLFILEFLG) (RETURN *]
and see if your problem goes away or
(b) advise(PUTHASHFILE BEFORE (AND PLVLFILEFLG (HELP] to see if you
are inadvertantly setting that flag somewhere.

	Bill

16-Jun-81 08:15:29-PDT,0000332;000000000001
Date: 16 Jun 1981 0815-PDT
From: David E. Smith <CSD.SMITH>
Stanford Phone: (415)497-1809
Subject: Key length
To: csd.greiner

Well, looks like Bill found the problem.  I suggest we change the length to
about 12, this will mean roughly 5-10 pages for the index.  The only change
necessary is to UF-CREATE.  -- de2
-------
16-Jun-81 11:36:41-PDT,0000000472;000000000001
Date: 16 Jun 1981 1136-PDT
From: CSD.GREINER
Subject: Re: PLVLFILEFLG
To: vanMelle at PARC-MAXC
cc: csd.greiner, CSD.SMITH
In-Reply-To: Your message of 15-Jun-81 2216-PDT

Yes - CORLL uses garbage collects to bump units -- and there's no reason a GC
couldn't occur during a ?=, or any other time.  
Dave: Can you make this fix to CORLL (when you're correcting the UF-CREATE
error)?

Thanks Bill.  As usual your sleuthing has helped immensely.
	Russ
-------
16-Jun-81 15:44:44-PDT,00000000259;000000000001
Date: 16 Jun 1981 1544-PDT
From: David E. Smith <CSD.SMITH>
Stanford Phone: (415)497-1809
Subject: Re: PLVLFILEFLG
To: CSD.GREINER
In-Reply-To: Your message of 16-Jun-81 1136-PDT

Make what fix?  CORLL already sets PLVLFILEFLG during UP-PUT.
-------
16-Jun-81 15:49:33-PDT,00000366;000000000001
Date: 16 Jun 1981 1549-PDT
From: David E. Smith <CSD.SMITH>
Stanford Phone: (415)497-1809
Subject: Re: [vanMelle at PARC-MAXC: PLVLFILEFLG]
To: CSD.GREINER
In-Reply-To: Your message of 16-Jun-81 1137-PDT

I spoke too soon.  Still, UP-PUT does a (SETQ PLVLFILEFLG NIL) which, though not
as nice as a RESETVARS, should still fix the problem.  -- DE2
-------
16-Jun-81 15:59:18-PDT,00000000464;000000000001
Date: 16 Jun 1981 1559-PDT
From: David E. Smith <CSD.SMITH>
Stanford Phone: (415)497-1809
Subject: The culprit surfaces!
To: CSD.GREINER

Aha!  I just looked and the "(SETQ PLVLFILEFLG)" was in the old PUTHASHFILE,
hence it disappeared when we switched hash packages.  That explains everything.
I should have checked sooner, but I was sure it was in UP-PUT.  -- de2

Go ahead and fix UF-CREATE while you're at it.  Twelve should be reasonable.
-------